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Abstract — The Constellation Program (CxP) Orion vehicle 
goes through several areas and stages of processing before 
its launched at the Kennedy Space Center. In order to have 
efficient and effective processing, all of the activities need to 
be analyzed. This was accomplished by first developing a 
timeline of events that included each activity, and then each 
activity was analyzed by operability experts and human 
factors experts with spacecraft processing experience. This 
papers focus is to explain the results and the process for 
developing this human factors operability timeline analysis 
to improve the processing flow of Orion. 1 2 
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1. Introduction 

The Constellation Program (CxP) Orion vehicle goes 
through several areas and stages of processing before its 
launched at the Kennedy Space Center. During all of the 
stages of this flow the ground processes were analyzed. This 
was accomplished by first developing a timeline of events 
that included each activity, and then each activity was 
analyzed by operability experts and human factors experts 
with spacecraft processing experience. A human factors 
analysis tool was adapted for this activity. Several human 
factors, and operations experts were brought together for a 
small team to perform this analysis. Following each issue 


discovered during the analysis the necessary analysis design 
engineering was brought into the process in order to address 
the issue for design improvements. 


2. Purpose and Driver of Timeline Analysis 

The purpose of the timeline analysis was to look at each step 
of the ground processing of the Orion vehicle as it goes 
through the different stages of processing at KSC, with an 
human factors and operations eye on the hardware human 
interactions affecting the human performance during 
assembly, maintenance, inspection of Orion at KSC. 

When an issue was discovered in the timeline, applicable 
standards were married with the issue. These standards 
mainly came from the FAA Human Factors Design 
Standards (HFDS). This process was basically stripping out 
the applicable FAA requirements that apply to ground 
processing of Orion, given the operations methodologies 
specially derived by the GOP to meet the CxP directives for 
CxP. The requirements derived during this exercise may or 
may not be applicable to another vehicle. If the processes 
are different during a different timeline, then another 
analysis would need to be performed. 


3. Timeline Overview 

The Orion processing time line includes Delivery from the 
Orion assembly line (located at KSC), Orion Processing in 
Multi Purpose Processing Facility, Orion/Ares Integration 
and Testing in the Vehicle Integration Building (VAB), Pad 
Operations, Landing and Recovery and. Post Flight 
processing. 

For each location a functional flow block diagram was 
developed. An example of the Functional Flow Block 
Diagram (FFBD) for the VAB is shown in figure 1. 
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With each of these high level areas, there are lower tiers of 
FFBDs. In those lower level FFBDs there are several tasks 
that take place. These tasks/activity are defined in the Orion 
Processing Flow during the Human Factors Operability 
Engineering Analysis (HFOEA). Each of those tasks were 
given an operations human factors engineering analysis. 


This human factors analysis included qualified human 
factors engineers, operations engineers and design engineers 
and the design visualization team. Prior to meeting with the 
human factors engineers, design visualation of the flight and 
ground hardware and humans were developed using the 
design visualation process. The visualization process is 
where the operations folks meet with the design 
visualization folks in the design visualization lab and 
reviewed the flight and GSE designs for human factors. 
These important meetings with the operations and design 


4. Analysis Methods and Development 

The analysis was basically a step by step processing going 
though each operations step to complete a task which would 
complete a block. Once one block was completed the next 
block was analyzed. The team modified a Human Factors 
Engineering Analysis (HFEA) tool developed by the KSC 
Engineering Directorate for the CxP GOP subsystems HFEA 
[2], basically by re-arranging the analysis spreadsheet to 
show a timeline of events. For each of the events the 5 areas 
in the tool were addressed. There are 5 major areas of the 
tool. They are; Human Interfaces, Issue, Processing Phase, 
Risk Analysis, and Recommendations. The first area is the 
human interface. This area includes; Location of process , 
Human/System Interface (H/SI), Human Interface , Task , 
FFBD Event Number, Task/Issues/Actions (TIA), and 
Conditions (The italicized were additions to the original 
HFEE Tool, these are shown in yellow in Figure 1.) The 
second area identifies the requirements to address the issues; 
the Requirement Source (RS) (typically FAA), the Section 
Title, (RST) Subsection Title (RSST), Requirements 
Verbiage (RV), if the requirement is satisfied or not (RS), 
and the primary verification method (PVM), which is 
Analysis, Inspection, Demo, or test. The third area included 
the processing phase (PP); Assembly/Installation, Nominal 
Use, Inspection, Maintenance, Off-Nominal Use, 
Emergency Use and Disassembly/ Disposal. The fourth 
section included the risk analysis section. Possible 
Consequences (PC), Priority Rank Likelihood (PRL), 



Figure 1 Modified HFEA Tool for Orion Processing Flow during the Human Factors Operability Engineering Analysis 

(HFOEA) 


engineers using the actual flight and ground designs loaded 
into the design visualization tools were a great help during 
the Human Factors Operability Engineering Analysis 
(HFOEA). 


Priority Rank Consequence (PRC), Priority Rank Product 
(PRP), and if currently none compliant the reason why 
(NCR). The fifth area provided; Potential Recommendations 
(PR), Notes (N), Team Action (TA), and comments for 
human factor video/animation improvements (CV). All of 
these areas are shown within the first row of the Modified 
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HFEA Tool, Figure 1. The grayed out row #2 is a closed 
issue, the rows in green are in work. 

5. Examples from the Analysis 

Several human factors issues from figure- 1 that will be 
explained here as examples. Because the information in the 
spreadsheet is too vast to fit into this paper, each cell will be 
explained in these examples. 

For Example #1 in the spreadsheet, the task of moving the 
short stack pallet into and out of servicing bay was 
evaluated. Alignment of pallet into the servicing bay was 
considered an issue that required further evaluation. An 
action was taken to assure a method is put in place to 
prevent contact and misalignment of pallet with existing bay 
structure during installation/removal of short stack pallet 
A human factors requirement was evaluated and applied to 
the task that states “Users shall be protected from making 
errors to the maximum possible extent”. A recommendation 
was provided to the design team to install guide rails on 
floor. The spreadsheet fields were populated as follows: 

• H/SI, - Short stack pallet. 

• TIAs - 

o TASK: Move short stack pallet into and 
out of servicing bay. 

o ISSUE - (Communication, visibility by 
operator to pallet corners): Alignment of 
pallet into bay. 

o ACTION - Assure method to prevent 
contact and misalignment of pallet with 
existing bay structure during 
installation/removal of short stack pallet 

• RS - FAA. 

• RST - 2-General Design Requirements. 

• RSST - 2.5.3 Error Resistant. 

• RV - “Users shall be protected from making errors 
to the maximum possible extent”. 

• PC - GSE damage, delay. 

• PP - Nominal Use and Maintenance. 

• PVM - Analysis. 

• PL - 2. 

• PRC - 2. 

• PRP - 4. 

• NCR - Conceptual design does not address this 
issue. 

• PR- Install guide rails on floor. 

• Notes - Maintenance is to address pallet storage 
without Orion Short Stack. 

• TA - Team Members to assess this human factors 
item and respond to team lead. 



For Example #2 in the spreadsheet, the task of connecting, 
disconnecting, and stowing hoses from transporter was 
evaluated. The weight and flexibility of the hoses was 
considered an issue. An action was taken by the team to 
assure the hoses can be lifted by the technicians. Human 
factors requirements for maximum weight of units of 
equipment to be carried by more than one person were 
assessed. If a unit of equipment is designed to be carried by 
two people, the weight carried by either one of them shall 
not exceed 19 kg (42 lb); thus, if the weight of the unit is 
distributed uniformly, the maximum weight of the unit is 38 
kg (84 lb). This limit applies to carrying distances up to 10 
m (33 ft). It was recommended to change the design of the 
hoses to be in sections to reduce weight to below these 
human factors requirements. The spreadsheet fields were 
populated as follows: 

• H/SI - ECS transport purge hoses and connectors. 

• TIAs - 

o TASK: Connect, Disconnect and stow 
ECS Hoses from KAMAG Source, 
o ISSUE - (Lifting, handling - pulling): 
Weight, flexibility of hose. The 

connection is low to the ground, 
o ACTION: Assure the hoses can be lifted 
by the technicians (Two person lift). 

• RS - FAA. 

• RST - 4.2.2 Weight. 

• RSST - 4.2.2.6 Maximum weight of units of 
equipment to be carried by more than one person. 

• RV - “If a unit of equipment is designed to be 
carried by two people, the weight carried by either 
one of them shall not exceed 19 kg (42 lb); thus, if 
the weight of the unit is distributed uniformly, the 
maximum weight of the unit is 38 kg (84 lb). This 
limit applies to carrying distances up to 10 m (33 
ft). Injury, GSE damage, delay.” 

• PC - Injury, GSE damage, delay 

• PPs - Nominal Use and Maintenance. Inspection. 

• 


PL -3. 
PRC - 2. 
PRP - 6. 
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• NCR - the lift requires more than 44 pounds per 
person and awkward postures. 

• PR - Consider making hoses in sections to reduce 
weight. The notes were, "History of back and 
shoulder injuries from similar tasks (disconnecting 
and storing these hoses at pad). See Gap 
Requirement (NIOSH lifting equation)for akward 
body positions. 

• TA - Rogelio to assess this human factors item and 
respond to team lead. The CV was that there was 
no human shown. 

For Example #3 in the spreadsheet, the task of removing 
guard rails from short stack pallet was also addressed. It 
had a similar issue to the hoses described above. The issue 
was for the weight and size of guard rails. An action was 
taken by the team to assure the guard rails can be lifted by 
the technicians. Similar human factors requirements 
applied. It was recommended that the design ensure 
manageable size and weight of the guard rails that meets the 
requirements. The spreadsheet fields were populated as 
follows: 

• H/SI - Short stack pallet guard rails. 

• The TIAs are 

o TASK: Remove guard rails from short 

stack pallet. 

o ISSUE (Lifting, handling and akward 
^positions): Weight and size of guard rails. 

o ACTION: Assure the guard rails can be 
lifted by the technicians (One or Two 
person lift). 

• RS - FAA. 

• RS - 4.2.2. 

• RST - 4.22 Weight. 

• RSST - 4. 2. 2. 6 Maximum weight of units of 
equipment to be carried by more than one person 

• RV - “If a unit of equipment is designed to be 
carried by two people, the weight carried by either 
one of them shall not exceed 19 kg (42 lb); thus, if 
the weight of the unit is distributed uniformly, the 
maximum weight of the unit is 38 kg (84 lb). This 
limit applies to carrying distances up to 10 m (33 
ft). 

• PC - Injury, GSE damage, delay. 

• PPs - Assembly/Installation, Nominal Use, and Off- 
Nominal Use. 

• PVM - Inspection. 

• PRL -3. 

• PRC - 2. 

• PRP - 6. 

• NCR - current conceptual design does not address 
this issue. 

• PR - Design manageable size and weight guard 
rails. The notes are that the guard rails are located (4) 
on the short stack pallet. 


• TA - Randy to forward to LM Short Stack pallet 
POC for disposition and respond to team lead. 

6. Lessons 

This section is a collection of lessons learned that will be 
documented into the NASA Integrated Lessons Learned 
system. http://nen.nasa.gov/portal/site/llis/LL/ Lessons 
learned include both positive lessons as well as lessons for 
making improvements. 

(1) The NASA CxP program level human factors 
requirements document HSIR greatly promoted better 
human factors Systems Engineering and Integration. 
This improved the integration between ground systems, 
crewed vehicle designs for ground processing [4]. 

(2) Early collaboration and planning between the flight 
and ground hardware designers for human factors 
operability engineering analysis (HFEA) is necessary. 

(3) Timeline analysis is great way to analyze and improve 
the design of ground and flight hardware interfaces for 
ground processing of the ground equipment, and the 
flight and ground hardware interfaceT 

(4) Although the HFOEA was primarily applied to Orion 
and GS to improve the design of hardware for better 
human factors and operations, some areas of HFOEA 
can be used to improve the work operations documents 
and processes. Example, for hazard warnings signs 
being called out in the work steps, etc. 

(5) Employ qualified human factors person/s on team from 
the beginning of the Project. 

(6) Human factors engineers should perform the human 
factors assessments as embedded members of the 
HFOEA design teams. 


7. Future Plans 

(I) Continue applying these processes and collaborations 
to future NASA missions in the 21 st Century. 
Specifically the timeline option to the Human Factors 
Engineering Analysis Tool (HFEAT) where applicable. 

Promote more design integration processes and designs 
between KSC, MSFC, and JSC, by using the timeline 
option for human factors operations engineering 
analysis. 

Promote sharing of this process across Centers, 
projects, and with commercial partners. 

Embed HFEA and HFOEA as part of the Engineering 
processes, as a decision tools to choose from for the 
appropriate human factors engineering analysis. 
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(5) Continue using the design visualization process, where 
operations met with the design visualization folks in 
the design visualization lab and reviewed the flight and 
GSE designs for human factors. These important 
meetings with the operations and design engineers 
using the actual flight and ground designs loaded into 
the design visualization tools were a great help. 

(6) Introduce motion capture analysis into applicable 
activities during the human factors operability 
engineering timeline analysis, especially where a 
worksite analysis is needed or where two or more 
projects interface, Ares/Orion/GO [3]. See Figure-2 
Motion capture allows for quicker and simpler and real 
to life simulations, and the computer models will 
include the CAD flight hardware and human Avatar 
which the envelope spaces between the human and 
flight hardware can be viewed, and the stresses to the 
human can be computed. See reference [3] for how 
motion capture was used during development of Orion 
for ground operations. See reference [4] for more on 
the CxP level 2 requirements that promoted better 
design of flight hardware for ground processing. 

(7) Promote more HFEOA timeline analysis with the 
ground support equipment, such as the flight and 
ground interface at the umbilical plates and the ground 
commodity connections to flight hardware. 

(8) Use the design problems and solutions from this 
HFEOA effort to improve the NASA STD 3001, to 
promote better NASA human factors Systems 
Engineering and Integration in future programs. 

(9) Employ the human factors systems engineering 
processes and lessons learned from Orion to future 
launch vehicles. 



Figure 2 Motion Capture of Operations inside the Orion 
vehicle. 


8. Conclusions 

This paper described the successful modification and 
application of the HFEA Tool for a timeline human factors 
operability engineering analysis for the Orion vehicle. 
Through this and other human interface analysis there was 
great progress made during CxP with collaboration between 
the Orion Project, Ground Operations Project and KSC 
Design Engineering. The most difficult and time consuming 
aspects of the development of these teams and analysis 
during CxP were during the forming, storming and norming 
stages, to get to the performing stages where we are today. 
Now that this has been accomplished, these methods and 
collaborations for human factors operability engineering 
analysis will continue to improve and carry over as we lead 
the nation in developing spacecraft systems for future 
missions. 
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